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Abstract 

To  enhance  systems  migration  planning,  including  acquisition,  implementation,  and  integration, 
an  approach  that  injects  executable  enterprise  information  technology  (IT)  architectures  into  the 
Department  of  Defense  (DoD)  planning  and  budgeting  processes  is  required.  Such  an  approach  is 
proffered  in  light  of  the  overarching  issue  and  debate  concerning  the  use  and  benefit  of 
generating  and  implementing  architectures. 

The  best  features  of  several  architectural  frameworks  are  woven  into  the  approach  discussed 
here.  Among  those  frameworks  are  the  John  Zachman  and  Steven  Spewak  concepts  and  the 
Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance,  and 
Reconnaissance  (C4ISR)  strategy  grounded  in  the  Air  Eorce  Horizon,  Navy  Copernicus,  and 
Army  Enterprise  architecture  methodologies.  Basic  to  these  architectural  approaches  is  the 
development  of  an  enterprise  business  model,  the  identification  of  the  tasks  and  activities 
performed  within  the  organization. 

The  approach  takes  the  information  systems  developer  from  operational  requirements  (reflected 
in  the  operational  architecture)  to  the  systems  infrastructure  (illustrated  in  the  systems 
architecture)  to  systems  evolution  (outlined  in  the  migration  plan).  By  generating  both  “As-Is” 
and  To-Be”  architectures  it  is  possible  to  create  a  roadmap  or  migration  plan  from  the  current 
information  environment  to  a  future  “end  state”  or  objective.  The  construction  of  these 
architectures  or  blueprints  is  best  accomplished  in  an  “architecture  studio.” 
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1.0  Introduction 


This  paper  addresses  the  commonly  asked  question,  “Why  do  architectures,  what  good  are 
they?”  The  answer  to  the  question  is  to  develop  dynamic,  executable  architectures  that  permit 
operations  improvements  supported  by  modeling,  analyses,  and  ‘what-if  gaming  studies.  To 
accomplish  these  goals,  architectures  must  become  an  active  player  in  the  Modernization 
Planning  Process  (MPP)  and  the  Planning  Programming  and  Budgeting  System  (PPBS). 
Architectures  must  therefore  provide  information  that  will  improve  the  effectiveness  of  both 
processes.  This  paper  discusses  how  architectures  should  be  developed  and  employed  in  a  way 
that  will  enhance  an  improved  migration  of  systems  and  capabilities  to  fulfill  the  visions  and 
needs  of  the  21st  century  defense  community. 

Starting  with  the  very  basics,  there  are  numerous  definitions  and  concepts  of  the  word 
‘architecture.’  Once  mentioned,  ‘architecture’  conjures  up  numerous  visions  and  carries  a  great 
deal  of  excess  baggage.  Two  definitions  will  be  used  in  this  paper  as  adopted  by  the  DoD  C4ISR 
Architecture  Framework.  Both  are  similar,  in  that  they  seek  to  define  the  relationships  and 
substance  of  an  entity  or  group  of  entities  and  how  the  relationships  between  both  should  evolve 
to  attain  a  goal  or  set  of  objectives: 

“A  framework  or  structure  that  portrays  relationships  among  all  the  elements 
of  the  subject  force,  system,  or  activity”  -  DoD  Joint  Pub  1-02 

“The  structure  of  components,  their  relationships,  and  the  principles  and 
guidelines  governing  their  design  and  evolution  over  time”  -  IEEE  Standard  610.12 

Architectures,  if  done  well,  synthesize  the  visions,  strategies,  requirements,  and  capabilities 
needed  for  sound  information  technology  (IT)  investments,  timely  technology  insertion,  and 
mission  capability  sustainment.  Architectures  also  provide  vital  activity  to  system  functional 
traceability,  process  reengineering,  and  information  systems  definition  and  planning.  This  is 
particularly  important,  in  light  of  recent  legislation  such  as  the  Information  Technology 
Management  reform  Act  (ITMRA)  and  the  Government  Performance  and  Results  Act  (GPRA). 
These  laws  require  DoD  organizations  to  measure  the  performance  of  existing  systems  and  the 
return  on  investment  for  planned  systems  and  to  report  these  statistics  on  an  annual  basis. 

The  overall  relationship  between  the  Air  Eorce’s  IT  architectural  development  process  and  the 
DOD  PPBS  is  illustrated  in  Eigure  1.  The  graphic  shows  the  interrelationship  among  the  various 
types  of  architectures  and  their  eventual  input  to  the  actual  systems  acquisition.  The 
architectures  also  inject  operational  needs,  systems  requirements,  and  technical  guidance  into  the 
Modernization  Planning  Process  documentation.  This  documentation,  in  turn,  should  function  as 
some  of  the  driving  forces  behind  the  mission  need  statements  in  the  Mission  Area  Plans.  The 
operational  requirements  then  flow  into  the  newly  established  Annual  Planning  and 
Programming  Guidance  (APPG)  which  directs  the  generation  of  the  Air  Eorce  POM  as  part  of 
the  PPBS,  the  cyclic  process  that  produces  the  DOD  portion  of  the  President’s  Budget  (PB) 
submission  to  Congress.  The  approved  budget  subsequently  permits  acquisition  of  needed  new 
or  modified  systems  [Riha  et  al,  1998]. 
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Figure  1  -  The  Architecture/PPBS  Relationship  [Riha  et  al.,  1998]. 


Underlying  this  issue  are  the  problems  of  how  better  to  identify  operational  requirements  for 
information  systems  and  the  insertion  of  emerging  information  technology  into  the  existing 
infrastructure  of  an  Air  Force  organization.  Along  with  this  problem  is  the  issue  of  how  to 
determine  gaps,  disconnects,  or  shortfalls  in  the  current  operations  and  systems  infrastructure  and 
capture  them  in  the  MPP  via  Mission  Area  Plans  and  Mission  Support  Plans  as  ‘ strategies -to- 
tasks’  and  ‘deficiencies.’  How  architects,  planners,  and  developers  envision  the  future  or  “to-be” 
operational/systems  environment,  and  subsequently  develop  a  systems  evolution  strategy  and/or 
plan  to  achieve  it  is  critical  to  success. 

This  paper  delineates  a  methodology  that  incorporates  operational,  systems,  and  technical 
architectures  (as  mandated  in  the  C4ISR  Architecture  Framework)  to  facilitate  convergence 
toward  compatible  information  systems,  accessible  information  in  a  shared  data  environment, 
compatible  databases  and  applications,  and  compatible  operating  procedures.  The  role  that 
C4ISR  Architecture  views  play  is  important.  The  operational  architecture  is  developed  to 
determine  the  operational  requirements  for  mission  connectivity  between  functional  elements  in 
order  to  accomplish  the  military  mission(s).  The  systems  architecture  is  then  established  to 
identify  the  appropriate  information,  communications  infrastructure,  and  systems  needed  to 
actuate  and  fulfill  the  operational  requirements.  The  technical  architecture  -  in  the  form  of 
standards,  guidelines,  and  technical  reference  codes  and  models  -  provides  the  control 
mechanism  to  guide  systems  toward  an  interoperable  configuration. 

Being  based  upon  the  operational  architecture,  the  entire  approach  is  built  upon  the  enterprise 
business  model,  the  delineation  of  the  functions,  tasks,  and  activities  of  the  organization.  This  is 


accomplished  by  first  developing  an  in-depth  business  model  of  the  enterprise’s  mission 
activities.  In  conjunction  with  the  business  model,  a  catalog  or  database  of  the  existing  systems, 
applications,  and  functions  that  are  used  to  perform  these  activities  is  populated.  The  products  of 
the  C4ISR  Operational  Architecture  are  generated,  providing  an  “As-Is”  depiction  of  the  existing 
information  exchanges,  operational  elements,  and  supporting  infrastructure. 

Operational  products  are  mapped  to  the  Systems  Architecture,  identifying  system-to-system 
interoperability  and  related  information  needlines  between  the  operational  elements.  By 
generating  both  “As-Is”  and  To-Be”  architectures  it  is  possible  to  create  a  roadmap  or  migration 
plan  from  the  current  information  environment  to  a  future  “end  state”  or  objective.  The  use  of 
System  Migration  Charts  are  key  during  this  phase  of  the  process. 

This  architecture  development  is  for  naught  if  the  results  and  products  simply  become  “shelf- 
ware”  and  are  not  actively  employed  in  the  systems  acquisition  process.  Here  lies  the  key  to 
improving  C4ISR  systems  acquisition.  Having  generated  both  operational  and  systems 
architectures,  in  both  an  “As-Is”  and  “To-Be”  perspective,  these  architectures  are  integral  to  the 
MPP-  especially  if  they  reside  in  a  web-based  environment  where  data  can  be  updated, 
manipulated,  and  extracted  easily..  Besides  operational  requirements  and  systems 

configurations,  the  architectures  provide  products  which  define  baseline  capabilities,  concepts  of 
operations,  operational  deficiencies,  improvement  concepts,  mission  objectives  and  tasks,  and 
other  supporting  data  vital  to  the  MPP. 

The  MPP,  in  turn,  is  infinitely  tied  to  the  DoD  PPBS  through  the  generation  of  the  Program 
Objective  Memorandum  and  President’s  Budget.  The  relationship  and  interdependence, 
however,  does  not  stop  there.  During  systems  acquisition  and  implementation,  the  architectures 
should  be  used  to  direct  systems  integration  by  identifying  implementation  concepts  between 
existing  legacy  and  newly  acquired  systems  and/or  between  evolving  capabilities.  Eventually, 
the  new  systems  become  part  of  the  new  “As-Is”  infrastructure  and  the  process  repeats  itself,  in  a 
continuous  spiral  of  technology  insertion  and  systems  applications. 

Just  as  Frank  Lloyd  Wright  brought  his  budding  architects  together  at  Talisien  and  Oak  Hill,  a 
parallel  concept  of  an  “Architecture  Studio”  for  the  development  of  information  technology  (IT) 
blueprints  is  addressed  in  this  paper.  The  collection  of  architecture  generation  tools  in  a  software 
laboratory  or  Architecture  Studio  where  business  modeling,  C4ISR  product  generation,  and  other 
engineering  analyses  can  be  accomplished  should  lead  to  better  integratable  architecture  products 
immediately  useable  by  the  systems  acquisition  community. 

In  this  approach,  particular  attention  is  devoted  to  C4I  issues  management,  identification  of 
operational  requirements,  and  the  systems  integration  strategy.  The  paper  describes  the  steps  of 
this  approach  in  detail  and  illustrates  its  cyclic  nature.  The  inevitable  relationships  between 
architectures,  planning,  budgeting,  and  acquisition  are  presented.  In  conclusion,  whereas,  parts 
of  the  approach  are  being  used  today-  this  approach,  in  its  entirety,  is  not  fully  ingrained  into 
DoD  processes.  The  approach  is  intended  to  represent  a  complete  package  encompassing 
operational  and  systems  architectures,  the  Modernization  Planning  Process,  and  the  Planning 
Programming  and  Budget  System. 


2.0  The  Process 


Architectures  are  the  guideline  for  the  process  of  developing,  maintaining,  and  evolving  the  force 
structure.  If  done  well,  the  product  is  interoperable  information  systems  and  integratable  forces. 
The  operational  architecture  is  the  key  to  the  entire  process  because  it  is  the  place  where  military 
visions  are  converted  to  capability  requirements  that  can  be  acted  upon  by  the  systems  and 
technical  architecture  planners  and  engineers.  If  the  process  does  not  start  with  the  operational 
architecture  there  is  the  risk  that  the  operational  visions  of  the  warfighter  will  not  be  optimally 
realized  [Beamer  and  Beckner,  1997]. 

The  system  architecture  is  where  operational  visions  and  requirements  merge  with  technology 
and  standards  to  become  hardware  and  software  reality.  Critically  important  to  this  process  is 
constructing  the  system  architecture  on  an  integrated  information  base  that  will  support  common 
systems  and  foster  information  superiority  across  US  forces  and  their  multinational  allies. 

The  technical  architecture  role  in  the  above  process  must  not  be  ignored.  The  warfighters  visions 
and  needs,  as  defined  in  the  operational  architecture,  become  state-of-the-art  capabilities  in  the 
systems  architecture.  They  leverage  on  the  research,  modeling,  testing,  and  standardization  of 
products  derived  through  technical  architecture  activities. 

The  three  architecture  views  must  be  integrated  together  to  optimize  the  military  force 
modernization  planning  effort.  Without  the  operational  architecture  to  represent  the  capability 
needs  of  the  systems  “owner”,  the  technical  architecture  “designer”  cannot  work  with  full 
success  with  the  “builder”  of  capabilities  through  a  systems  architecture  development  and 
evolution  plan  and  implementation  strategy.  If  any  of  the  three  legs  of  the  architecture  structure 
are  weak,  the  entire  modernization  planning  process  will  be  weak.  If  the  operational  architecture 
is  absent,  then  assumptions  on  what  the  owner  needs  and  wants  will  be  made  by  the  designer  and 
developer.  In  the  past  this  situation  has  lead  to  a  disappointed  owner-operator,  and  a  less  than 
optimal  force  capability  [Beckner  and  Norman,  1998]. 

Modernization  planning  in  the  US  military  environment  starts  at  the  top  with  National  Policy, 
Service  Missions,  DOD  Strategies,  Leadership  Visions  and  Command  Initiatives.  Typically  this 
level  of  planning  is  general  in  scope  and  goal  oriented.  The  vectors  thus  generated  are  usually 
turned  over  to  specific  commands  within  the  services  to  submit  for  funding  through  the  Program 
Objective  Memorandum  (POM),  program,  budget,  and  convert  the  visions,  concepts,  and 
operational  concepts  and  goals  into  military  realities  and  National  potential  [AFPD  10-14]. 

The  core  modernization  process  is  complex  as  can  be  seen  in  Figure  2.  Implementation  requires 
an  ordered  and  fully  orchestrated  set  of  events  that  encompass  the  vision,  planning,  acquisition, 
budgeting,  experiments,  battle  laboratory  training  and  sustainment  activities  of  an  organization 
or  command.  Although  the  final  product  of  the  modernization  process  is  the  Mission  Area  Plan 
(MAP),  documents  that  should  govern  and  guide  the  entire  process  are  the  architectures. 
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Figure  2.  Core  Modernization  Process 


The  actual  evolution  of  systems  from  the  current  “as  is”  architecture  configuration  to  the  desired 
future  “to  be”  state  requires  engineering  skill  and  administrative  cooperation.  The  engineering 
skill  activities  are  centered  on  evolving  systems  and  capabilities,  often  under  fiscal  constraints, 
from  the  “as  is”  configuration  to  the  “to  be”  configuration  without  lapses  in  operational 
readiness,  availability,  and  connectivity.  The  “to  be”  systems  architect  should  orchestrate  this 
process,  and  at  the  same  time,  champion  the  cause  for  funding,  testing,  and  fielding  the 
increments  as  they  are  delivered.  If  funding  shortfalls  occur,  or  delivery  schedules  slip,  the 
architect  must  adjust  the  evolution  plan  accordingly  to  avoid,  or  at  least  minimize,  the  impact  on 
operational  elements  of  the  force. 

3.0  Business  Modeling 

Business  modeling  is  the  process  of  defining  the  business  activities.  The  purpose  of  the  business 
model  is  to  provide  a  complete,  comprehensive,  consistent  knowledge  base  that  can  be  used  to 
define  the  architectural  views,  implementation  plans,  and  migration  strategies.  The  preliminary 
business  model  identifies  the  operational  functions,  provides  a  brief  description  of  each  function, 
and  determines  the  organization  unit  that  performs  each  function.  The  flow  of  information 
between  functions  is  also  captured. 

The  initial  task  is  to  document  the  structure  of  the  organization  and  identify  the  individuals  or 
nodes  and  their  locations  that  perform  the  business  functions.  The  key  is  to  chart  the  inherent 
structure  of  the  organization  and  to  identify  the  organizational  units  that  must  communicate  in 


order  to  accomplish  the  organization’s  mission(s).  This  information  can  be  obtained  through 
structured  interviews  and  review  of  organization  charts,  telephone  directories,  budgets,  and  other 
organizational  documents. 

Next,  the  actual  business  of  the  organization  is  identified  by  the  determination  of  the  tasks  or 
functions  performed  by  the  units  or  nodes  of  the  organization.  A  function  is  any  set  of  actions 
performed  in  the  course  of  conducting  business  [Spewak,  1992].  Delineating  the  functions  is 
essential  before  defining  the  operational  and  systems  architectures.  Organizational  activities  are 
collected  until  no  further  functional  decomposition  to  greater  levels  of  detail  is  possible. 

During  later  stages  of  architecture  development,  while  building  the  operational  and  systems 
views,  the  architect  and  business  activity  owner  will  determine  who  performs  the  functions. 
Also,  how  those  functions  are  performed,  where  and  when  it  is  accomplished,  the  priority  of  the 
functions,  the  technologies  and  resources  employed,  and  of  most  importance,  the  determination 
of  the  data  flows,  information  needlines,  and  other  interfaces  must  be  documented.  Having 
related  the  functions  to  the  organizational  elements  that  perform  the  functions,  the  architectural 
products  as  outlined  in  the  DoD  C4ISR  Framework  can  now  be  generated. 

It  ah  starts  with  the  business  model.  The  business  model  feeds  the  operational  architecture 
which,  additionally,  is  predicated  upon  the  concept  of  operations.  In  turn,  the  systems 
architecture  and  systems  migration  strategies  are  based  upon  the  organization’s  operations. 

4.0  Architecting 

Architectures  provide  a  mechanism  for  understanding  and  managing  complexity  [Zachman, 
1997].  Well-developed  architectures  improve  capabilities  by  enabling  the  quick  conversion  of 
well-defined  requirements  into  sound  investments  that  are  time-phased  to  meet  operational 
needs.  The  current  challenge  is  to  implement  a  methodology  that  will  facilitate  the  development 
and  use  of  architecture  products  in  a  way  that  will  be  cost  effective,  interactive,  and  timely.  The 
solution  is  to  maximize  the  use  of  information  technology  in  a  comprehensive  planning 
environment.  The  vehicle  is  an  Advanced  Planning  Architecture  Studio,  or  simply,  the 
Architecture  Studio. 

The  architecture  studio  concept  embraces  the  idea  of  providing  a  workplace  for  the  architect.  As 
with  any  good  work  environment,  the  studio  should  have  the  hardware,  software,  and 
connectivity  needed  to  do  the  job  quickly  and  efficiently.  Depending  on  the  scope  of  the 
architecture,  the  architects’  studio  could  be  a  workstation  at  a  desk,  or  a  series  of  workstations  in 
a  room  or  facility  that  is  configured  specifically  for  architectural  work.  The  former  situation 
might  be  appropriate  for  a  small  organization.  The  latter  might  work  best  for  a  large 
organization  that  would  focus  more  on  a  team  construct  where  recognized  best  practices  are  used 
with  recognized  tools  to  achieve  design  and  development  goals  consistent  with  the  common 
architecture  picture  view  of  any  domain  or  set  of  domains. 

An  effective  architecture  studio  should  include  an  architecture  development  library.  This  library 
should  be  centered  around  an  on-line  system  that  has  access  and  web  connectivity  to  architecture 
development  references  such  as  the  C4ISR  Architecture  Framework,  software  tools,  and  other 


information  appropriate  to  the  architecture  development  effort.  The  architecture  library  can  also 
be  the  repository  for  the  architecture  products  as  they  are  developed.  An  enterprise-wide 
architecture  development  library  could  be  the  repository  for  multiple,  related  architectures  which 
could  share  common  products  such  as  the  data  dictionary. 

The  architecture  studio  could  be  configured  for  multiple  uses.  One  use  might  be  as  an 
environment  where  OPLAN  and  network  planning  development  activities  could  have  direct 
access  and  interface  with  architects  and  system  developers.  Another  use  might  be  for  modeling 
and  simulation  of  systems  and  capabilities  needed  to  satisfy  deployment  and  employment  needs 
on  a  near  real-time  basis.  The  architecture  studio  should  be  the  operations  center  for  current  and 
future  planning.  The  ultimate  architecture  studio  and  OPLAN  development  “facility”  would 
exist  in  a  collaborative  virtual  workspace  environment  [Beckner  and  Norman,  1998]. 

The  supervisor  of  the  Architecture  Studio  should  be  the  architect.  The  architect  is  the  person 
charge  of  the  architecture  and  those  working  to  define,  refine,  and  maintain  the  architecture 
products  and  database.  The  role  and  skills  of  the  architect  should  not  be  confused  with  that  of 
the  engineer.  Although  the  architect  may  be  an  engineer,  the  engineer  and  architect  require 
different  types  of  skills  and  perspectives  to  perform  their  specific  and  distinct  duties.  The 
activities  of  the  architect  and  engineer(s)  are  summarized  in  Table  1.  As  can  be  seen,  the 
architect  and  the  engineer(s)  must  work  together,  supplementing  the  other’s  knowledge  and  both 
understanding  the  goals  and  constraints  needed  for  the  architecture  to  be  successful  [LaCroix, 
1998]. 


Development  Activities 

Engineer 

Architect 

Active  realm 

Technical 

Political  &  Technical 

Focus 

Quantitative 

Qualitative  &  Quantitative 

Uses 

Analytic  Tools 

Knowledge  &  Experience 

Applies 

Physical  Science 

Inductive  Reasoning 

Derives 

Specific  Solutions 

Broad  Guidelines 

Assesses 

Cost 

Operational  Worth 

Responds  to 

Architect/Client 

Client 

Concerned  with 

System  Components 

Inter-Relationships 

Knowledge  Base 

Specialty  Depth 

User  Environment 

Objective 

Technical  Elegance 

Military  Utility 

Primary  Discipline 

Science 

Art  and  Science 

Delivery  Goal 

Built  to  Specifications 

Certified  for  Use 

Table  1.  Engineer  and  Architect  Activities 


Ultimately  the  architect  is  responsible  for  the  physical  and  conceptual  integrity  of  the  capability 
as  seen  by  the  client,  builder,  and  all  the  stakeholders.  The  role  of  the  architect  is  not  trivial.  It 
should  not  be  delegated  to  individuals  or  organizations  with  average  experience  or  skills. 


It  is  important  for  the  architect  to  be  able  to  calculate  the  approximate  cost  of  developing  and 
maintaining  the  architecture  and  its  products.  Knowing  approximately  what  the  cost  can  be  will 
assist  in  budgeting  for  the  effort,  which  in  turn  will  help  insure  that  the  products  are  sustained  in 
current  and  useable  form  over  their  lifetime.  Tables  have  been  formulated  to  help  determine  the 
cost  of  developing  architectures  and  their  products  [Beckner  and  Norman,  1998].  These  tables 
estimate  the  cost  of  staffing  the  architecture  task  focusing  on  effort  versus  dollar,  and  identify  the 
basic  hardware  and  software  that  the  architecture  team  may  need  to  do  the  work.  Overhead  and 
life  cycle  costs  can  be  extrapolated  from  these  basic  tables. 

An  architecture  staffing  matrix  can  also  be  used  to  estimate  the  number  of  staff  years  needed  to 
develop  and  sustain  each  architectural  product.  The  military.  Civil  Service,  or  contractor  grade 
range  of  the  individual  that  would  be  expected  to  do  the  task  is  indicated  in  the  matrix.  The 
matrix  presumes  that  the  persons  assigned  to  the  architecture  development  task  are  qualified  for 
the  task  in  accordance  with  the  criteria  established  by  the  architect.  The  key  factors  to  consider 
are  contractors’  corporate  knowledge,  architecture  development  experience,  and  access  to  the 
current  and  future  information  needed  to  produce  non-proprietary  architecture  views  and 
products. 


Objective 

Activity 

Overview 

Tasks 

Staffing 

Grade  Quantity 

Annual 

Cost 

Administer 

Program 

•  Determine  architecture 
type(s)  (Operational, 
Systems,  Technical)  to 
be  developed. 

•  Scope  Architecture 
(Time/Phase  of  interest, 
geographical/ 
organizational  limits) 

•  Define  Process  (Top 
Down,  Bottom  Up, 
Current  and/or  Euture) 

•  Define  minimum  set  of 
products  *  and 
publishing  media  (paper 
or  website) 

•  Cost  &  Schedule 

•  Supervisor/Architect 

-  Define  Process  and 
regulate  costs 

-  Obtain  Content  OPRs 

-  Define  and  deliver 
architecture/products 

-  Complete  AV-1* 

•  Administrative  Asst. 

•  Webmaster  (if 
applicable) 

05/GS13  1.0 

E-7  0.4 

E-5  0.3 

$59K 

$11K 
$  6K 

(Estimatec 

)  Number  of  Staff  Years  Required  1 .7 

(Estimated)  Annual  Eabor  Cost  of  Overhead  $76K 

*  Essential  C4ISR  Architecture  Product 

*  The  minimum  set  of  products  should  include  all  the  essential  C4ISR  Architecture  Eramework 
products.  Other  C4ISR  and  non-C4ISR  products  needed  should  be  defined  and  the  cost  estimated. 

Table  2.  Architecture  Development  Administration 


The  cost  of  initially  developing  an  architecture  and  its  products  may  be  different  from  sustaining 
the  product  once  developed.  For  example,  it  may  take  a  very  experienced  person  with  wide 
systems  knowledge  to  develop  the  product  or  architecture,  but  a  less  experienced  (perhaps  even  a 
more  specialized)  person  or  organization  to  maintain  the  data  currency  once  the  product  is  in  use. 
The  estimated  annual  personnel  cost^  to  administer  an  architecture  development  program  is 
provided  in  Table  1?.  The  annual  cost  of  sustaining  the  architecture,  once  developed,  is 
somewhere  between  25  and  35%  of  the  initial  cost. 

Once  developed,  architectures  and  architecture  products  must  be  made  available  for  use. 
Traditionally,  the  process  has  been  to  publish  paper  copies  and  send  them  to  a  list  of  offices  and 
agencies  that  are  likely  to  use  the  information.  This  process  is  rapidly  becoming  obsolete  due, 
primarily,  to  the  need  to  get  current  information  to  a  myriad  of  users  in  the  shortest  time 
possible.  The  alternative  is  to  host  the  architecture  in  a  web  environment. 

The  primary  advantage  to  hosting  the  architecture  and  its  products  in  the  web  environment  is  the 
speed  of  access  and  flexibility  in  using  the  products.  It  is  also  possible  to  make  almost  real-time 
updates  to  the  architecture  instead  of  waiting  for  the  “next  revision”  to  be  published  and 
distributed^.  The  speed,  flexibility,  and  availability  of  electronic  publishing  allow  architectures 
to  be  an  active  player  in  the  planning  and  development  strategy  of  an  organization. 

4.1.  Integrating  Architectural  Methods 

The  Office  of  the  Assistant  Secretary  of  Defense  for  Command,  Control,  Communications,  and 
Intelligence  (OASD  (C3I))  and  Joint  Staff  J6  in  conjunction  with  the  CINCs,  Services,  and 
Agencies  has  established  a  set  of  architectures  which  are  designed  to  provide  a  coordinated 
architecture  design  approach  [OSD  Letter,  1998].  This  approach  ensures  a  common  denominator 
for  understanding,  comparing,  contrasting,  and  integrating  architectures  across  the  DOD.  This 
has  been  promulgated  in  the  form  of  the  C4ISR  Architecture  Framework.  This  document, 
currently  in  Version  2.0,  standardizes  architectures  to  three  views:  Operational,  Systems,  and 
Technical  [C4ISR  Framework,  1997].  The  Architecture  Framework  also  contains  a  general 
outline  of  the  content  expected  in  each  of  the  three  types  of  architectures.  Use  of  the  C4ISR 
Architecture  Framework  is  the  directed  format  for  all  architectures  in  the  DOD^. 


^  All  salary  costs  were  calculated  using  the  Defense  Finance  and  Accounting  Service  Monthly  Basic  Pay  chart, 
effective  1  Jan  1998,  and  the  U.S.  Office  of  Personnel  Management  1998  General  Schedule,  effective  January 
1998. 

^  Similar  tables  have  been  constructed  to  define  each  of  the  26  Version  2.0  C4ISR  Architecture  Framework 
products  and  their  estimated  development  costs  [Beckner  and  Norman,  1998]. 

^  The  long-term  cost  of  publishing  in  a  web  environment  cost  effective  when  compared  to  publishing  and 
distributing  paper  copies. 

^  It  is  important  to  understand  that  the  C4ISR  Architecture  Framework  provides  direction  on  how  to  describe 

architectures,  not  how  to  design  or  implement  a  specific  architecture,  or  how  to  develop  and  acquire  a  system  or 
systems. 


The  C4ISR  Architecture  Framework  is  intended  to  ensure  that  the  architectures  developed  by  the 
geographic  and  functional  Unified  Commands,  military  Services,  and  defense  Agencies  are 
interrelateable  between  and  among  the  organizations’  operations,  systems,  and  technical 
architecture  views,  and  are  comparable  and  integratable  across  Joint  and  multi-national 
organizational  boundaries.  The  C4ISR  Architecture  Framework  supports  the  warfighter  by 
providing  a  common  framework,  definition  and  methodology  for  architectures  across  the  DOD. 
The  Framework  ensures  that  DOD  C4ISR  systems  migrate  towards  compliance  with  DOD 
technical  architecture  guidance.  It  also  provides  a  comprehensive  plan  by  which  in-depth 
analysis  of  specific  architectural  issues  that  cut  across  architectures  can  be  identified  and 
resolved 

Currently  many  organizations  develop  architectures.  Establishing  the  C4ISR  Architecture 
Framework  standard  definitely  makes  the  understanding  and  comparison  of  these  architectures 
easier.  Establishing  the  capability  to  integrate  architectural  views  within  an  operational  or 
functional  domain,  and  between  functional  domains  facilitates  the  integration  of  needs, 
processes,  and  capabilities.  The  ability  to  integrate  between  and  across  architectures  facilitates 
sound  and  consistent  technical  planning  decisions  and  reduces  costs.  The  benefits  of 
integrateable  architectures  has  enhanced  planning  decisions  and  is  beginning  to  reap  benefits  at 
the  joint  and  multinational  level  as  well  as  at  the  Service  level.  Secondary  benefits  such  as 
training  planners  to  develop  architecture  products  and  the  dissemination  of  the  architecture 
products  also  greatly  benefit  from  the  standardizing  effect  of  this  initiative. 

4.1.1  The  Zachman  Framework 

In  “A  Framework  for  Information  Systems  Architecture  f  John  Zachman  [1987]  identified  an 
easy  to  comprehend  methodology  for  developing  an  enterprise  information  architecture.  His 
framework  has  become  a  de  facto  standard  for  enterprise  architecture  design.  Zachman’ s 
framework  is  intended  to  provide  a  method  to  control  decentralization  issues  within  an 
organization. 

The  Zachman  framework  was  one  of  the  first  approaches  that  illustrated  the  need  for  separate 
data,  process,  and  technology  architecture  views  within  the  concept  of  an  enterprise  information 
architecture.  Data  flows,  business  processes,  and  applied  technologies  are  investigated  across 
the  organization  (or  enterprise),  each  with  an  individual  orientation  while  being  integrated  to 
portray  the  whole  [Cook,  1996]. 

The  various  architectures  are  simultaneously  developed  by  moving  through  sequential  levels  of 
detail  while  investigating  the  nature  of  the  organization.  Melissa  Cook  [1996],  in  Building 
Enterprise  Information  Architectures,  compares  the  Zachman  levels  of  detail  and  the  iterative 
process  used  to  populate  the  framework  to  those  employed  in  designing  a  house  or  other  physical 
building.  This  analogy  will  later  be  used  to  advocate  the  creation  of  an  IT  architecture  studio. 

The  levels  of  architectural  views  in  the  Zachman  framework,  ranging  from  the  broadest  to  the 
most  detailed  are: 

•  The  Ballpark  View 

•  The  Owner’s  View 


•  The  Designer’s  View 

•  The  Builder’s  View 

•  The  Detailed  Representation 

•  The  Functioning  System 

For  each  of  these  levels,  the  Zachman  framework  identifies: 

•  What  data  is  exchanged 

•  How  the  function  is  performed  that  handles  the  data 

•  Where  within  the  network  is  the  function  performed 

•  Who  are  the  people  performing  the  functions 

•  When  is  the  function  accomplished  within  the  concept  of  operations 

•  Why  is  the  function  performed,  in  support  of  which  business  goal 

Consequently,  the  Zachman  framework  is  portrayed  as  a  six-by-six  matrix.  Each  of  the  36 
entries  in  this  matrix,  illustrates  an  architectural  product  that  leads  to  an  integrated  enterprise 
architecture.  The  Zachman  Framework  is  very  useful  for  placing  the  planning/definition  stages 
into  a  conceptual  framework.  It  organizes  the  architectural  development  into  manageable 
segments.  The  framework  does  not  explain  how  to  populate  the  matrix  or  how  to  actually 
implement  the  architectures  in  the  enterprise. 

4.1.2  Enterprise  Architecture  Planning 

Steven  Spewak’s  Enterprise  Architecture  Planning  (EAP)  is  a  process  for  defining  architectures 
for  the  use  of  information  in  support  of  the  business  and  the  plan  for  implementing  those 
architectures  [Spewak,  1992].  Key  here  is  the  concept  of  using  the  results  of  architecting  to 
identify  requirements  and  plan  for  the  implementation  of  systems,  and  their  eventual  acquisition. 

Dr.  Spewak  contends  that  “architectures  are  founded  on  a  functional  business  model.” 
Consequently,  the  EAP  approach  starts  with  the  identification  of  the  organization’s  functions  and 
activities.  While  interviewing  staff  to  ascertain  these  functions,  the  architect  also  identifies  the 
current  systems  and  technologies  at  work  within  the  organization.  Armed  with  the  knowledge  of 
the  existing  systems  and  the  functions  performed  by  the  staff  using  these  systems,  preliminary 
‘AS-IS’  operational  and  systems  architecture  can  be  generated. 

The  next  phases  of  the  EAP  methodology  look  at  the  future  environment  of  the  enterprise.  A 
data  architecture  is  developed  in  which  the  data  entities  are  determined.  These  data  entities  are 
the  categories  of  information  which  are  exchanged  by  the  nodes/elements  of  the  enterprise. 
Next,  an  applications  architecture  is  generated  in  which  the  existing  and  needed  software 
applications  or  systems  are  identified.  The  purpose  of  the  applications  architecture  is  to  define 
the  major  kinds  of  applications/systems  required  to  manage  the  data  and  support  the  business  of 
the  enterprise.  Easily,  the  technology  architecture  is  developed.  The  objective  of  this 
architecture  is  to  define  the  major  technologies  needed  to  provide  an  efficient  operational 
environment.  A  technology  deployment  plan  is  generated  illustrating  the  sequenced  insertion  of 
emerging  technologies  into  the  systems  infrastructure  of  the  enterprise  [Spewak,  1992]. 


Having  accomplished  an  EAP  study,  the  architect  has  populated  the  first  two  rows  of  the 
Zachman  matrix  and  as  the  final  product,  publishes  an  Implementation  Plan  for  the 
implementation  of  the  architectures  and  acquisition  of  the  applications.  With  higher 
management  buy-in,  the  implement  plan  lies  out  the  roadmap  for  systems  migration  within  the 
organization. 

4.2.  Populating  Architectures 

It  takes  an  architect  to  populate  an  architecture.  And  it  takes  a  team  of  architects  and  a  great  deal 
of  time  to  generate  an  architecture.  No  one  architect  can  be  expected  to  know  the  entire  breath 
and  depth  of  the  enterprise.  Therefore,  the  IT  architect  must  also  rely  upon  and  collect 
information  from  a  large  number  of  people  and  organizations  from  within  the  enterprise  under 
investigation. 

The  architect  must  become  infinitely  knowledgeable  of  the  enterprise.  The  concept  of  operations 
must  be  characterized,  the  operational  nodes  or  elements  identified,  and  the  information 
exchanges  between  the  nodes  need  to  be  thoroughly  investigated  and  described.  The  information 
and  communications  systems  used  by  the  enterprise  must  be  cataloged  and  their  interfaces 
delineated.  Architectural  views  of  the  existing  operational  and  information  environment  must  be 
generated  in  order  the  establish  an  “AS-IS”  baseline  or  foundation  [Beamer  and  Beckner,  1997]. 

Next,  the  architect  must  become  a  magician,  and  look  into  his  or  her  crystal  bah.  Actually  it  is  a 
little  more  scientific  than  that,  there  are  existing  systems  engineering  practices  and  procedures 
for  making  engineering  estimates  and  predictions  of  the  future  predicated  on  current  operations 
and  situations.  In  this  phase  of  architecture  development,  the  architect  is  generating  the  “TO- 
BE”  architectures.  Through  review  of  organization  documentation  and  other  literature, 
interviews  and  surveys,  and  business  practice  studies-  the  architect  can  determine  the  needed 
operational  concept  for  future  operations  of  the  enterprise.  This  includes  optimization  of 
interfaces,  identification  of  needed  nodes,  and  determination  of  information  needlines.  The 
planned  operational  activities  of  the  future,  in  turn,  allow  the  architect  to  postulate  the  target  or 
“TO-BE”  systems  infrastructure  of  the  future  for  the  enterprise. 

The  architect  populates  the  architecture  by  collecting  operational,  functional,  systems 
information  via  a  variety  of  data  collection  methodologies.  These  can  include,  but  are  not 
limited  to:  face-to-face  interviews,  telephone  surveys,  written  questionnaires  and  surveys,  and 
review  of  appropriate  documents  such  as  concepts  of  operations,  operations  plans,  strategic 
plans,  and  Air  Eorce  Instructions. 

The  architecture  database  should  be  hosted  in  a  tool  that  provides  object  oriented  relational 
manipulation  of  the  data,  query  language  searches  and  sorts,  web  browser  connectivity  to  the 
internet,  and  other  data  analysis  capabilities.  A  number  of  such  tools  are  on  the  commercial 
market  and  this  is  not  the  place  to  address  the  specifics  of  these  products  or  to  indorse  one  over 
another.  Suffice  it  to  say,  the  tool  must  permit  the  architect  the  ability  to  generate  and  populate 
both  graphical  representations  of  the  architectures  and  supporting  textual  databases. 


5.0  Managing  Systems  Evolution 


No  architecture,  no  matter  how  good,  can  accomplish  much  if  it  is  not  implemented.  To 
implement  anything  takes  management  initiatives,  attention  to  the  details  necessary  for  success, 
and  a  plan.  The  first  step  in  the  planning  process  is  to  define  and  bound  the  problem.  A  set  of 
questions  has  been  developed  to  assist  the  architect  in  satisfying  this  need.  Each  question  is 
cross-referenced  to  the  product  descriptions  in  the  C4ISR  Architecture  Framework  to  assist  in 
understanding  the  basic  aspects  that  should  be  considered  [Beckner  and  Norman,  1998]. 

Architecture  Councils  are  evolving  as  an  effective  way  to  govern  and  guide  the  development  of 
architectures  across  domains.  Ideally  a  council  includes  expert  representation  across  their 
domain  of  interest.  The  councils  established,  however,  must  avoid  becoming  a  forum  for 
discussion  without  progress.  This  can  be  avoided  through  leadership  and  membership  restricted 
to  individuals  who  will  aggressively  pursue  their  chartered  responsibilities.  The  responsibility  for 
a  council’s  success  should  lie  with  the  Senior  Officer  over  the  Council  Chairperson. 

An  example  of  how  a  set  of  councils  could  be  established  is  at  Figure  3.  Councils  such  as  this 
should  be  established  at  a  level  that  will  ensure  enterprise- wide  cognizance  and  oversight. 


Figure  3.  Architecture  Council  Structure 


One  of  the  primary  responsibilities  of  an  Integrated  Enterprise  Council  would  be  to  ensure  that 
the  other  councils  retain  an  integrated  view  of  the  enterprise  and  strive  for  joint  force 
interoperability.  To  do  this  the  Air  Force,  for  example,  would  work  through  the  MAJCOM, 
Base,  Agency  or  Domain  System  Integration  Management  Organization  (SIMO)^.  As  shown  in 
Figure  3,  the  organizational  SIMO  Chairperson  would  probably  serve  as  the  organization 
representative  on  the  Integrated  Enterprise  Council.  This  council  could  also  serve  as  an 
overarching  Enterprise  Configuration  Control  Board  [Beckner  and  Norman,  1998]. 

5.1  The  Development  Process 

One  of  the  ways  that  architectures  can  be  closely  correlated  is  by  basing  them  in  the  context  of  a 
global  strategy.  Joint  Vision  2010  and  the  Global  Engagement  Strategy  are  both  intended  to 
provide  an  operational  strategy  to  exploit  the  full  spectrum  of  US  military  operations.  The 
foundation  of  this  strategy  includes  promoting  stability  with  alliances  and  coalitions  and 
maintaining  a  multi-mission  capable  force  that  can  smoothly  transition  from  peacetime  security 
activities  to  multi-theater  wars.  Included  in  this  strategy  is  the  ability  of  US  forces  to  respond  to 
two  overlapping  conflicts  and  asymmetric  attacks.  The  Expeditionary  Aerospace  Force  concept 
is  the  Air  Force  vehicle  for  accomplishing  these  goals. 

Air  Force  Policy  Directive  (AFPD)  10-14,  Modernization  Planning,  recognizes  the  need  to 
continually  refine,  update,  and  correct  the  mission  and  support  objectives  and  tasks  [AFPD  10- 
14,  1995].  The  process  by  which  this  is  done  is  called  the  Modernization  Planning  Cycle. 
Modernization  Planning  follows  the  timing  from  AFPD  10-14.  The  objective  is  to  price, 
prioritize,  and  integrate  products  that  could  influence  the  Air  Force  POM  before  POM 
submission.  Each  MAJCOM  uses  the  AF  Manual  1-1  as  a  guide  to  establish  mission  area 
responsibilities  throughout  this  process  [AFM  1-1,  1992]. 

Air  Force  Modernization  Planning  Cycle  is  designed  to  support  the  POM  activities  by  providing 
the  needed  status  and  requirements  information  to  senior  Air  Force  leaders  at  scheduled  decision 
points  such  as  the  Corona  Briefings  and  key  presentations  such  as  the  Defense  Program 
Guidance  (DPG),  which  directly  influence  the  POM  development. 


^  The  concept  of  a  SIMO  was  adopted  and  put  into  use  by  the  DOD  Intelligence  Information  Systems  (DODIIS) 
community.  The  purpose  of  the  SIMO  is  to  provide  a  structured  methodology  to  identify  and  document  systems 
architecture  goals.  The  SIMO  also  plans  cost-effective,  operationally  focused  implementation  of  these  goals; 
monitors  the  status  of  critical  activities  associated  with  the  plan;  executes  the  transition  from  existing  to  desired 
baselines;  and  communicate  results  of  analysis,  transition  status,  issues,  and  resolution  plans,  and  makes 
recommendations  to  senior  management.  The  DODIIS  SIMO  program  has  been  very  successful  and  is  used 
widely  by  various  DOD  Unified  and  Specified  Commands,  MAJCOMs,  and  Agencies.  The  SIMO  concept 
provides  a  forum  for  feedback  for  operators,  planning  and  verification  for  maintainers,  schedules  and  status  for 
developers,  C2  plans  and  requirements  for  warfighters,  security  guidance  for  information  systems  security 
managers,  project  plans,  schedules  and  status  for  project  action  officers  and  commitment  from  senior  managers. 
The  process  provides  a  needed  interface  in  a  structured  manner  to  insure  that  all  aspects  of  systems 
development — from  inception  to  retirement — are  understood.  From  this  forum  come  consolidated 
understandings  and  courses  of  action. 


The  POM  is  a  biennial  memorandum  submitted  by  the  Secretary  of  Defense  (SecDef)  from  each 
Military  Department  and  Defense  agency.  Each  POM  proposes  total  program  requirements  for 
the  next  six  years.  Included  in  the  submission  is  the  rationale  for  planned  changes  from  the 
approved  Future  Years  Defense  Program  (FYDP)  baseline  within  SecDef  fiscal  guidance. 

The  process  starts  in  the  “Out  of  Cycle  (with  the  POM)  Year”  with  the  Mission  Area  Assessment 
(MAA).  The  MAA  refines  the  guidance  provided  by  Headquarters  USAF  in  the  Air  Force 
Strategic  Plan.  The  next  step,  the  Mission  Needs  Analysis  (MNA),  refines  task  to  need.  Here 
the  MAJCOMs  analyze  the  force  structure,  geopolitical  environments,  projected  advances  in 
technology,  interoperability  concerns,  and  expected  threats  affecting  their  current  and 
programmed  capabilities  to  accomplish  a  task.  From  this  analysis  deficiencies  in  current  and 
future  capabilities  are  identified.  A  Mission  Need  Statement  (MNS)  is  then  developed  to 
document  specific  materiel  deficiencies  that  the  MAJCOMs  cannot  correct  through  non-materiel 
solutions  such  as  adjusting  doctrine,  tactics,  and  training.  An  Operational  Requirements 
Document  (ORD)  is  usually  associated  with  the  MNS.  The  ORD  identifies  the  operational 
requirements  necessary  to  meet  the  identified  need.  All  Air  Force  ORDs  must  be  accompanied 
by  a  Requirements  Correlation  Matrix  (RCM).  The  RCM  is  a  matrix  spreadsheet  outlining  the 
user’s  operational  requirements  in  terms  of  capabilities  and  characteristics. 

A  Mission  Area  Plan  (MAP)  is  the  primary  product  of  the  Air  Force  POM  process.  MAPs  cover 
periods  of  25  years  and  use  the  products  of  the  MAA  and  MNA  to  document  the  most  cost- 
effective  corrections  of  task  deficiencies.  A  MAP  is  comprised  of  individual  weapon’s 
system/capability  roadmaps  with  a  modernization  plan  and  descriptions  of  enabling  technologies 
that  can  be  expected  to  correct  the  task  deficiencies.  Air  Force  functional  areas  such  as 
command,  control,  communications,  and  computers,  security  police,  intelligence,  or  civil 
engineering,  may  develop  similar  plans  called  a  Mission  Support  Plan  (MSP)  to  serve  this  same 
purpose. 

The  MAP  and  its  supporting  equivalent,  the  MSP,  identify  the  strategy  necessary  to  achieve 
goals.  The  actual  development  and  evolution  of  systems  and  capabilities,  however,  is  governed 
largely  through  technically  oriented  details  contained  in  documents  such  as  the  MNS  and  ORD. 

MAJCOMs  integrate  MAPs  and  MSPs  to  provide  the  fiscal  prioritization  across  their  areas  of 
responsibility^.  The  integration  must  be  sufficiently  detailed  to  support  Air  Force  modernization 
planning  through  the  Biennial  PPBS  cycle.  The  MAJCOMs  also  coordinate  with  supported 
CINCs  to  prioritize  Research,  Development,  and  Acquisition  (RD&A)  programs  to  support  the 
MAPs. 

Committees  of  senior  Air  Force  leaders  (i.e.,  the  AF  Group,  Board,  and  Council)  review  the 
MAJCOM  program  lists  and  any  associated  funding  disconnects  with  fiscal  limits  that 
MAJCOMs  cannot  resolve.  The  committees  reprioritize  programs  if  necessary  and  recommends 
for  the  Chief  of  Staffs  approval  corrections  of  task  deficiencies  that  meet  fiscal  constraints. 


^  MAJCOMs  may  request  Theater  CINC/Component  Commander  inputs  prior  to  MAA  completion  and  can  include 
functional  area  (e.g.,  intelligence)  and  mission  support  area  considerations  in  their  MAPs.  HQ  AFMC  supports 
the  preparation  of  MAAs,  MNAs,  and  MAPs/MSPs  through  Technical  Planning  Integrated  Product  Teams.  The 
ACISRC  coordinates  C2  MAP  across  the  Air  Force. 


The  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS),  in  consultation  with  the  other  members  of  the 
Joint  Chiefs  of  Staff  and  the  combatant  commanders,  also  has  an  input  to  the  process  of 
developing  the  overall  budget  for  military  expenditures.  The  objective  of  the  CJCS  input  is  to 
ensure  that  strategic  plans  and  direction  for  the  Armed  Forces  are  consistent  and  will  interact  in  a 
positive  manner  with  all  other  DOD  systems.  The  JSPS  is  the  formal  process  used  by  the  CJCS 
for  reviewing  the  national  security  environment  and  US  national  security  objectives,  threat 
evaluation,  assessment  of  current  strategy,  existing  and  proposed  budgets,  and  the  programs  and 
forces  necessary  to  achieve  all  national  objectives.  Taken  together,  the  JSPS  and  the  PPBS  have 
a  combined  purpose  of  furnishing  the  best  possible  mix  of  missions,  forces,  equipment,  and 
support  to  the  combatant  commanders  [AFPD  10-14]. 

5.2  Implementing  the  Architecture 

Clearly  the  magnitude  of  the  architecture  and  planning  activity  across  an  organization  should  be 
simplified  and  standardized  to  the  greatest  degree  possible.  This  is  necessary  to  make 
architectures  understandable,  compatible,  integratable,  and  not  redundant,  overlapping,  or 
unnecessary.  There  also  needs  to  be  a  top-level  view  of  the  enterprise.  The  top-level  view 
should  reflect  the  substance  of  the  common  infrastructure  and  the  ability  to  interoperate  with  the 
other  organizations  (Services  and  Agencies),  and  allies. 

An  example  of  the  evolution  to  the  concept  is  shown  in  Figure  4.  As  can  be  seen,  a  seamless  and 
integrated  view  of  the  nodes  and  connectivity  within  and  between  nodes  and  systems  is  highly 
desirable.  To  succeed  the  integrated  architecture  should  also  be  an  evolving  and  forward-looking 
architecture — one  that  can  be  referenced  to  determine  the  course  of  evolution  of  systems  and 
capabilities.  To  be  effective  the  repository  of  enterprise-wide  connectivity  and  interoperability 
should  reside  in  a  widely  accessible  media  such  as  a  web  environment.  The  database  should 
reflect  the  current  systems  and  structure  plus  the  vision  of  the  future.  The  future  vision  should  be 
time-phased  and  contain  the  needs,  programs  and  schedules  in  effect.  All  known  issues, 
including  those  dealing  with  funding  should  also  be  resident  and  available  for  access,  review, 
resolution,  and  update.  The  focus  should  be  on  the  information  systems  that  make  up  the 
command  and  control  systems.  The  emphasis  should  be  on  developing  the  commonality 
between  systems  and  capabilities  that  will  result  in  a  common  robust  information  infrastructure 
with  tentacles  to  specific  mission  systems  and  needs  [Spewak,  1992]. 

One  of  the  primary  purposes  in  generating  architectures  should  be  to  support  the  acquisition 
process.  Operational  architectures  define  user  needs  in  terms  of  what  is  needed  (capabilities/ 
activities  and  information/data  models),  where  it  is  needed  (nodes),  who  needs  the  information 
(information  exchanges),  and  how  to  provide  information  system  capabilities  to  support  the  users 
(operational  activity  to  system  function  traceability  matrix),  and  other  systems  architecture 
products.  A  time-phased  approach  to  implementing  the  information  system  capabilities  is 
provided  by  defining  the  current  and  projected  operational  architecture  products  and  defining  the 
system  evolution  to  meet  these  needs  over  time.  As  previously  indicated,  the  systems  evolution 
description  can  be  the  foundation  of  the  information  technology  budget  (and  defined  in  the 
information  technology  portion  of  the  POM). 


Figure  4.  Integrated  Architecture  Evolution 


5.3  Building  Capabilities 

Figure  5  highlights  the  system  engineering  activities  needed  to  develop  capabilities  within  the 
Air  Force.  The  systems  architecture  plays  a  key  role  in  each  of  these  steps  from  requirement 
correlation  to  fielding  of  capabilities  at  the  architectural  nodes  that  apply. 

The  return  arrow  in  Figure  5  emphasizes  the  beneficial  tie  between  the  architecture  update  cycle 
and  the  formal  Air  Force  Modernization  Planning  Cycle.  This  tie  allows  updated  products  to  be 
available  for  use  during  the  annual  Air  Force  PPBS  and  POM  activities. 

The  Air  Force  Modernization  Planning  process  should  also  benefit  from  several  recent  initiatives 
that  focus  on  capabilities  planning  and  development.  These  include  the  initiative  to  conduct 
annual  “live  fly”  Expeditionary  Force  Experiments  (EEX).  The  objective  of  the  EEX-series 
experiments  is  to  identify  technologies  and  capabilities  that  should  rapidly  be  assimilated  into  the 
warfighters  weapons  inventory.  The  “Eive  Ely”  experiments  test  the  capabilities  developed  in  a 
realistic  manner  with  the  warfighter  involved  to  the  maximum  extent.  If  there  are  changes  or 
modifications  needed,  they  will  be  identified  here.  If  not,  the  capability  is  manufactured  and 
fielded  in  the  shortest  time  possible.  To  complement  this  objective  acquisition  agencies  are  now 
focusing  on  a  spiral  development  cycle  needed  to  continue  their  work. 


Figure  5.  Core  Implementation  Process 


Architecture  views  are  being  used  to  support  EFX  execution  and  spiral  development  evolution. 
The  C4ISR  Architecture  Framework  provides  the  means  for  accurate  and  equitable  comparisons 
between  domain  architectures  within  the  Air  Force  and  across  the  DOD  to  support  a 
consolidated,  architecture -based  modernization  process. 

Figure  6  is  an  overview  of  the  traditional  Air  Force  development  process  starting  with  what  is 
needed  militarily  as  stated  in  policy,  assigned  mission  tasks,  strategy  and  other  initiatives.  The 
command  planning  found  in  architectures,  CONOPs,  and  various  Master  Plans  establish  the 
priorities  for  accomplishing  what  is  needed.  The  acquisition  community  responds  to  the 
command  planning  with  analyses,  MNS,  ORD,  and  other  development  programs.  Those  to  be 
evolved  become  part  of  the  Spiral  Development  process.  These  are  developed  and  validated  in  a 
realistic  unified  command  and  control  battlespace  environment  and  at  battle  laboratories.  When 


Figure  6.  The  Planning  Process 


they  will  be  provided  to  the  warfighter  is  reasonably  predictable  due  to  the  goals  and  controls  of 
the  Spiral  Development  process.  Programs  which  do  not  build  upon  existing  systems  usually 
enter  the  development  process  through  the  development  of  a  Statement  of  Work  (SOW)  and 
specifications.  The  SOW/Specification  methodology  is  becoming  less  predominant  than  in  past 
years,  mostly  due  to  the  shortage  of  funds  to  start  “new”  developments,  and  because  the 
emphasis  on  the  DII  COE  and  other  initiatives  designed  to  build  on  COTS  products  and  evolve 
capabilities  instead  of  developing  unique  military  systems  . 

Ensuring  that  evolution,  by  the  spiral  development  methodology,  benefits  from  the  leading  edge 
of  competent  technology  is  extremely  important  to  the  successful  use  of  the  developed  capability 
by  the  warfighter.  The  step  of  infusing  technology  into  the  process  must  be  considered  and 
successfully  implemented.  The  simultaneous  application  of  agreed  upon  standards  is  also  critical 
to  joint  interoperability  goals  and  requirements. 


An  understanding  of  how  the  overall  process  works  is  important  to  defending  funding  expenditures.  A 
challenged  program  of  capabilities  at  the  lowest  level  should  be  able  to  trace  its  origin  back  to  some 
requirement  higher  in  the  process,  and  ultimately  to  National  Policy.  If  a  level  of  the  planning  process  has  been 
bypassed,  or  some  key  document  is  missing  or  does  not  exist,  e.g.,  an  operational  architecture,  then  justifying 
the  development  may  be  in  jeopardy. 


5.4  Spiral  Development 


The  Spiral  Development  process  depicted  in  Figure  7  is  focused  on  rapid,  thorough,  and 
continuous  evolution  of  capabilities  for  the  warfighter.  The  thrust  of  the  concept  is  guided  by  the 
Systems  and  Technical  Architecture  products  and  the  needs  expressed  in  the  mission  area  and 
mission  needs  analyses  that  are  part  of  the  POM  process.  The  Spiral  Development  process  has 
set  a  goal  of  completing  one  cycle  of  capability  development,  testing,  evaluating,  and  training 
within  a  notional  18-month  period.  At  the  end  of  each  18-month  cycle  capabilities  identified  in 


Figure  7.  Spiral  Development 

the  Evolution  Plan  should  be  available  for  use  in  the  field,  and  would  be  deployed  immediately 
upon  operator  approval  without  an  interruption  in  service  or  the  requirement  to  operate  both  the 
“old”  system  and  the  “new/upgraded”  system  at  the  same  time.  Simultaneously,  the  cycle 
continues  with  added  technologies,  user  feedback.  Defense  Advanced  Research  Projects  Agency 
and  battle  laboratory  technology  insertions,  and  in-house  analysis^.  The  cycles  continue  toward 


^  The  Spiral  Development  Team  should  maintain  contact  with  the  battle  laboratories  and  agencies  doing  research 
and  testing.  The  development  team  is  in  the  position  to  know  that  a  system  or  capability  is  in  the  evolution 
process.  Once  the  contact  has  been  made,  it  is  the  responsibility  of  all  parties  to  ensure  that  an  atmosphere  of 
coordination,  cooperation,  and  mutually  beneficial  exchange  of  information  is  maintained. 


goals  set  by  the  Operational  Architectures  and  the  DPG.  Using  this  process  the  capabilities 
provided  for  each  operational  and  functional  domain  would  continuously  be  improved  and  new 
capabilities  would  be  fielded  much  more  quickly  and  at  less  cost  than  by  the  traditional  methods 
used  in  the  past. 

5.5  An  Architectural  Example 

The  authors  have  been  involved  with  several  information  technology  architecture  development 
efforts  during  the  past  decade.  One  project  warrants  description  in  this  paper  as  it  employed 
precepts  and  methods  extracted  from  several  architectural  approaches.  The  project  was  called 
the  Headquarters  Air  Force  (HAF)  Information  Architecture  Planning  (lAP)  Study  and  followed 
the  basic  tenets  of  Steven  Spewak’s  Enterprise  Architecture  Planning  (EAP)  approach. 

Staff  were  selected  from  each  of  the  Deputy  Chief  of  Staff  (DCS)  organizations  from  within  the 
Headquarters  Air  Eorce  to  study  the  HAE  information  infrastructure  and  develop  an  architecture 
implementation  plan.  One  or  two  representatives  from  each  DCS  were  assigned  to  the  HAE  lAP 
Core  Team.  The  Core  Team  functioned  for  thirteen  months  (5  Jan  98  to  1  Eeb  99)  with  members 
participating  for  as  short  as  two  months  or,  as  in  most  cases,  the  entire  duration  of  the  study. 
Membership  on  the  Core  Team  was  determined  both  by  the  skill  mixed  and 
experience/background  needed  on  the  team  during  particular  phases  of  the  study  and  by 
availability  of  personnel  being  released  from  their  regular  duties  within  the  various  DCS. 

As  the  HAE  lAP  Core  Team  developed  the  Enterprise  Architecture  Implementation  Plan,  an 
oversight  committee  was  established  called  the  Reference  Croup.  This  group  consisted  of  0-6 
(full  colonel)  or  equivalent  members,  once  again,  representing  each  of  the  DCS  organizations 
within  Headquarters  Air  Eorce.  The  Reference  Croup  met  monthly,  on  a  regular  basis,  and  also 
‘as  needed’  to  review  specific  products  of  the  Core  Team  before  these  products  were  eventually 
presented  to  an  executive  steering  group. 

Eor  this  study,  the  role  of  the  executive  steering  group  was  performed  by  the  Air  Eorce  Chief 
Information  Officer’s  (CIO)  Management  Board  (MB).  The  board  consists  of  the  Air  Eorce 
CIO,  the  Deputy  CIO,  the  Assistant  Vice  Chief  of  Staff  of  the  Air  Eorce,  and  the  Deputy  Chiefs 
of  Staff  from  a  number  of  the  DCS  organizations  such  as,  but  not  limited  to:  SAE/AQ,  AE/SC, 
SAE/EM,  AE/IE,  AE/XO,  AE/XP,  and  AE/RE.  The  AE  CIO  MB  empowered  the  HAE  lAP  Core 
Team  with  access  throughout  the  Headquarters  within  the  Pentagon  and  granted  authority  for  the 
Team  to  conduct  interviews  and  distribute  questionnaires  and  surveys  as  needed  in  order  to 
perform  their  studies. 

In  essence,  the  HAP  lAP  Core  Team  constituted  a  team  of  architects  working  in  an  Architecture 
Studio.  The  Core  Team  was  provided  a  separate,  secluded  facility  in  which  to  meet  on  a  daily 
basis  and  to  conduct  its  operations.  Core  Team  members  supported  the  HAP  lAP  effort  full  time 
during  their  tenure  on  the  team  and  reported  to  the  team  facility  for  duty.  The  team  was 
physically  located  within  walking  distance  to  the  Pentagon. 


Initially,  all  Core  Team  and  some  Reference  Croup  members  were  trained  in  the  Spewak  EAP 
methodology.  This  consisted  of  a  one  week  formal  seminar  (conducted  twice,  Jan  98  and  July 


98)  and  periodic  “just  in  time”  training  sessions  before  each  subsequent  phase  of  the  study.  Two 
or  three  Spewak,  Inc.  associates  facilitated  the  Core  Team  activities  at  all  time  throughout  the 
thirteen  month  effort. 

The  goal  was  to  populate  the  first  two  rows  of  the  John  Zachman  Framework  matrix  by 
employing  Steven  Spewak’ s  EAP  processes  for  the  enterprise  of  the  Headquarters  Air  Force. 
The  final  product  of  a  Spewak  EAP  study  is  an  Implementation  Plan  for  the  Enterprise 
Architecture  that  is  developed  and  a  prioritized  set  of  projects  or  applications  to  be  acquired  to 
attack  the  information  deficiencies  of  the  organization  and  fill  information  management  gaps. 

The  first  step  was  to  develop  a  set  of  information  management  principles  or  first  tenets  to  guide 
the  entire  effort  and  to  be  adapted  by  the  enterprise  (Headquarters  Air  Eorce)  as  a  whole.  The 
Core  Team  generated  a  set  of  17  principles,  which  were  approved  by  the  AE  CIO  MB  in  July  of 
1998.  In  parallel  with  principle  development,  the  team  set  to  work  generating  a  business  model 
of  all  the  activities  and  tasks  performed  in  the  HAE.  Eventually,  after  months  of  study  and 
intensive  interviewing  and  surveying,  a  business  model  of  238  functions  was  produced.  Eor  each 
function,  the  team  ascertained  which  organization  was  responsible  for  the  function,  why  it  was 
performed,  which  mission  was  supported,  the  inputs  and  outputs  to  the  activity,  which  systems 
were  employed,  and  several  other  characteristics  of  the  function. 

A  subgroup  of  the  lAP  Core  Team,  also  in  parallel  with  the  above  efforts,  started  the  Current 
Systems  and  Technology  phase  of  the  Spewak  EAP  methodology.  This  team  collected 
information  on  the  existing  automated  information  systems  (AIS)  that  are  used  within  the  HAP. 
These  are  the  systems  that  are  employed  to  perform  the  functions  that  are  delineated  in  the 
business  model.  Also,  collected  were  the  information  technologies  that  are  inherent  in  the 
systems.  The  team  published  an  Information  Resource  Catalog  (IRC)  of  the  nearly  250  systems 
used  by  the  staff  of  the  Headquarters  Air  Eorce. 

With  a  business  model  of  the  HAP  established,  a  catalog  of  existing  systems  and  a  listing  of 
utilized  technologies  captured  in  an  Access  database,  the  team  could  begin  to  construct  parts  of 
both  an  “AS-IS”  Operational  and  Systems  Architecture  based  upon  the  guidance  in  the  DoD 
C4ISR  Architecture  Pramework  document.  An  Operational  Concept  graphic  was  generated,  a 
node-to-node  connectivity  diagram  was  drafted,  an  information  exchange  matrix  was  populated, 
activity  trees  were  generated,  organization  charts  printed,  and  a  logical  data  model  created  as 
parts  of  an  “AS-IS”  Operational  Architecture. 

Then  the  Core  Team  turned  its  attention  to  developing  data,  application,  and  technology 
blueprints  for  the  future  information  needs  of  the  HAP.  During  the  interview  and  survey  phase 
of  the  effort,  the  team  collected  data  on  deficiencies,  disconnects,  information  flow  needs, 
opportunities  for  improvements,  and  other  gaps  in  the  functioning  of  the  headquarters.  Using 
Spewak  EAP  techniques,  the  team  analyzed  the  collected  data  and  generated:  data  entities  for  the 
HAP,  a  list  of  needed  “TO-BE”  applications,  technology  deployment  plans,  technology  position 
statements,  and  a  set  of  prioritized  capability  improvement  projects  (CIPs). 


The  final  product  of  the  effort,  The  Implementation  Plan,  delineated  the  acquisition  strategy  for 
the  prioritized  CIPs.  The  plan  illustrated  a  time  phased  implementation  schedule  for  the 
acquisition  and  integration  of  the  CIPs  into  the  HAF  information  environment.  Staff  from  the 
Air  Force’s  Electronic  Systems  Center  was  enlisted  as  part  of  the  effort  to  facilitate  integration  of 
the  capability  improvement  projects  and  to  acquire  new  applications,  as  applicable. 

Most  recently,  in  February  of  1999,  the  lAP  EAP  effort  was  subsumed  into  a  newly  formed 
organization,  with  the  charter  to  oversee  and  act  as  a  central  point  of  contact  for  information 
management,  information  systems  acquisition,  and  general  information  operations  for  the 
Headquarters  Air  Eorce.  This  organization  was  named  the  Headquarters  Information  Planning 
Program  Office  (HIPPO)  and  is  administratively  part  of  SAE/AA  (Secretary  of  the  Air  Eorce, 
Administrative  Assistant). 

Thus,  the  HAP  lAP  was  one  of  the  first  efforts  to  utilize  a  structured  enterprise  architecture 
methodology,  sequester  a  team  of  “architects”,  analyze  an  enterprise,  generate  architectures, 
delineate  solutions  in  the  form  of  capability  improvement  projects,  and  actually  begin  the  process 
of  acquisition  through  the  spiral  development  approach  of  the  Electronic  Systems  Center  (ESC). 

6.0  Conclusions 

The  tools  and  techniques  provided  in  the  C4ISR  Architecture  Eramework  are  designed  to  put 
products,  programs,  capabilities,  activities,  relationships  and  applications  in  a  context  that 
streamlines  analysis  and  integrates  visions  and  knowledge  in  a  common  format  that  can  be  used 
efficiently  by  planners  and  decision  makers.  The  power  of  the  C4ISR  concept  lies  in  its 
compliance  with  Eederal  mandates  and  its  use  throughout  the  DOD.  Using  architecture  products 
to  complement  and  strengthen  the  Air  Eorce  modernization  planning  and  POM  process  is  basic 
to  good  management  of  resources. 

The  facility  where  operations,  planning,  architectures,  and  development  decisions  come  together 
is  the  Architecture  Studio.  Architecture  Studios  are  in  being  and  are  being  used  to  define  and 
plan  complex  systems  for  warfighting  CINCs.  Once  the  plan  has  been  established  in  the 
architecture  studio,  it  is  ready  for  the  Spiral  Development  process  and  implementation.  The 
architecture  studio  never  closes.  It  continues  to  monitor,  record,  and  guide  the  evolutionary  steps 
of  the  Spiral  Development  process.  By  doing  this,  it  is  always  ready  and  available  to  do 
replanning  based  on  suddenly  appearing  operational  requirements  or  fiscal  changes. 

The  Spiral  Development  process  usually  functions  as  a  continuous  process.  A  good  example  is 
the  recent  Air  force  initiative  to  treat  Command  and  Control  as  an  overarching  capability  instead 
of  an  adjunct  to  stovepiped  systems.  This  initiative  was  a  major  step  in  the  unifying  of  the  Air 
Eorce  portion  of  the  DOD  Eorce  structure.  Erom  this  basis  has  grown  the  consolidation  of 
thought  and  effort  that  has  resulted  in  a  more  consistent  global  view  of  capabilities.  This  view 
stresses  how  Commercial  off  the  Shelf  (COTS)  products,  guided  by  common  information 
communications  and  operating  environment,  and  joint  architecture  management  councils,  can 
develop,  produce,  and  field  capabilities  that  capture  Joint  Vision  2010  goals. 


Injecting  the  results  of  the  spiral  development  process  into  the  fiscal  modernization  equation  is  a 
highly  desirable  technique  that  could  benefit  the  funding  of  developing  systems  and  capabilities. 
Use  of  the  development  information  provided  by  the  spiral  development  process  could  clearly 
indicate  what  the  latest  technology  has  produced  or  is  about  to  produce.  This  knowledge  should 
be  invaluable  to  guiding  supplemental  development  programs  that  will  take  full  advantage  of 
current  technology  and  developments  and  linking  them  to  the  POM  process. 

Getting  feedback  from  the  warfighter  and  the  activities  of  the  battle  laboratories  into 
architectures  is  vital.  There  must  be  continuous  dialog  between  the  CINCs,  Services, 
Component  Commands,  Agencies,  and  architecture-OPLAN  developers.  The  responsibility  for 
this  process  lies  at  the  Joint  and  Service  organizations.  This,  however,  does  not  relieve  the  field 
commands  and  agencies  from  their  responsibilities  to  coordinate  and  disseminate  information  of 
mutual  interest. 

The  key  to  successful  evolution  strategy  for  subsystems  and  capabilities  is  updating  selected 
management  processes.  What  needs  to  be  done  is  to  migrate  from  “stove  pipe”  engineering  and 
development  to  council-based  engineering.  Likewise  there  needs  to  be  a  migration  from  myopic 
systems  analysis  and  capabilities  definition  to  DOD-centric  developments  and  decisions  which 
focus  on  integrated,  joint,  and  in  some  cases  multinational,  engineering.  Inherent  in  the  Spiral 
Development  concept  are  requirements  for  redefining  the  management  processes  to  consolidate 
program  budgeting  along  the  lines  of  specific,  approved  capability  sets.  To  efficiently  achieve 
the  goals  established  for  the  next  century,  the  POM  process  needs  to  be  amended  to 
accommodate  the  evolving  changes  in  the  management  processes. 
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